Operators use different middlebox services or appliances, called inline services, such as Deep Packet Inspection (DPI), logging/metering/charging/advanced charging, Firewall, Intrusion Detection and Prevention (IDP), Network Address Translation (NAT), etc., to manage subscribers' traffic. These services have high requirements on throughput and packet inspection capabilities. They can be transparent or nontransparent to the end users. Inline services can be hosted in dedicated physical hardware, or in virtual machines.
Service chaining is required if the traffic needs to go through more than one inline service. Moreover, if more than one chain of services is possible, then the operator needs to configure the networking infrastructure to direct the right traffic through the right inline service path. Traffic steering refers to leading the traffic through the right inline service path.
There have been some efforts to determine how to steer traffic to provide inline service chaining. The mechanisms developed through those efforts are designed to explicitly insert the inline services on the path between end-points, or explicitly route traffic through different middleboxes according to policies.
The requirements for any traffic steering solution are: efficiency, flexibility, scalability, and openness. With respect to the efficiency requirement, traffic should traverse middleboxes in the sequence specified by the network operators and should not unnecessarily traverse middleboxes. Great capacity expansion (CAPEX) savings could be achieved if traffic could be selectively steered through or steered away (bypassed) from specific services.
With respect to the flexibility requirement, the framework should support subscriber, application, and operator specific policies simultaneously, all stemming from a single control point. Adding or removing new services should be easily implemented by the network operator.
With respect to the scalability requirement, the framework should support a large number of rules and scale as the number of subscribers/applications grows. The ability to offer a per-subscriber selection of inline services could potentially lead to the creation of new offerings and hence new ways for operators to monetize their networks.
With respect to the openness requirement, deployment of any type of middlebox in the network should be possible. Deployment of the middlebox should be vendor independent in order to avoid vendor lock-in. Further, network operators should be able to leverage their current investment by reusing their existing middleboxes without modifications.
In general, operators use policy-based routing (PBR) to forward subscriber traffic towards the right services. Operators may also use access control lists (ACLs) and virtual local area networks (VLANs) (other tunnelling techniques) to forward packets to the right place.
In some cases, service chaining can be partly performed by the services themselves, leaving less control to the operator over the remaining hops in a service path. In this case, the services must be configured to direct traffic to the next hop in the chain if the service box is not directly connected to the next hop.
FIG. 1 illustrates an example of inline service chaining for residential traffic 115 and enterprise traffic 120. In this example, it is assumed that residential traffic will need DPI 140 and NAT 125. Premium residential traffic receives the same services as basic residential in addition to firewall and URL filtering (URL filtering not shown). Enterprise traffic will not require NAT but will need firewall (FW) and virus scanning (VS). In this example, all traffic goes through the DPI 140 and returns to the BNG 105, also shown at point (1) in the FIG. 1. From there (point 2 in FIG. 1) the BNG 105 has to direct the traffic to the right next hop service, e.g., NAT 125, FW 130, VS 135. The subscriber session Authentication, Authorization, and Accounting (AAA) driven policy 110 can define the first hop service; however, this subscriber context information is no longer associated with the return traffic from the DPI 140 at point (1). Hence, determining the next service for a specific flow becomes non-trivial.
One approach to providing services is to use a single box that runs multiple services. This approach consolidates all inline services into a single box and, hence, avoids the need for dealing with inline service chaining configuration of the middleboxes. The operator adds new services by adding additional service cards to its router or gateway.
The single box approach cannot satisfy the openness requirement as it is hard to integrate existing third party service appliances. This solution also suffers from a scalability issue as the number of services and the aggregated bandwidth is limited by the router's capacity. The number of slots in chassis is also limited.
A second approach to providing services is to use statically configured service chains. One or more static service chains is configured. Each service is configured to send traffic to the next service in its chain. A router classifies incoming traffic and forwards the traffic to services at the head of each chain based on the result of the classification.
The statically configured service chain approach does not support the definition of policies in a centralized manner and instead requires that each service be configured to classify and steer traffic to the appropriate next service. This approach requires a large amount of service specific configuration and is error prone. It lacks flexibility as it does not support the steering of traffic on a per subscriber basis and limits the different service chains that can be configured. Getting around these limitations would require additional configuration on each service to classify and steer traffic.
A third approach to providing services is policy based routing (PBR). With the PBR approach a router using PBR is provided. Each service is configured to return traffic back to the router after processing the traffic. The router classifies traffic after each service hop and forwards the traffic to the appropriate service based on the result of the classification. However, the PBR approach suffers from scalability issues as traffic is forced through the router after every service. The router must be able to handle N times the incoming traffic line rate to support a chain with N−1 services.
Finally, a fourth approach to providing services is using a policy-aware switching layer. A policy-aware switching layer for data centers explicitly forwards traffic through different sequences of middleboxes. Using this approach satisfies the efficiency requirement but fails to meet the requirements of flexibility and scalability. Each policy needs to be translated into a set of low level forwarding rules on all the relevant switches. There is no explicit way to configure application related and subscriber related rules separately. They need to be manually consolidated into a set of low level rules. Moreover, this approach requires installing one rule for each new flow. Therefore, it is hard to scale with the number of subscriber/application combinations.
As stated previously, there are multiple schemes used to steer traffic in a network. However, the problem of where to connect services to the network so that total performance is optimized still exists.